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FOREWORD 


The  Jiffy  Game  has  existed,  as  a manual  war  game,  since  the  late 
1960 's.  In  its  early  stages,  the  game  was  completely  manual;  and 
correspondingly,  its  assessment  methodology  was  simplistic,  based  on  the 
firepower  scores  of  a few  key  weapon  systems.  In  late  1973,  USATRADOC 
established  the  Scenario  Oriented  Recurring  Evaluation  System  (SCORES), 
the  standard  scenario  development  process  to  be  based  on  the  Jiffy  Game. 
With  the  advent  of  SCORES,  it  was  recognized  that  the  simplistic, 
firepower  score-driven  Jiffy  Game,  although  responsive,  was  not  of 
adequate  resolution  to  produce  the  quality  product  expected  from  SCORES. 
Thus,  the  Jiffy  Game  underwent  major  methodology  modifications,  which 
allowed  the  gaming  of  the  complete  spectrum  of  conventional  weapon  systems 
and  upgraded  the  assessment  methodologies  to  use  weapon  characteristics 
Instead  of  firepower  scores  as  the  basis  for  assessments.  However,  as 
the  level  of  detail  increased,  the  number  of  manual  calculations  and  the 
amount  of  data  required  to  make  the  calculations  also  increased.  Finally, 
it  became  necessary  to  automate  the  assessment  calculations  to  maintain 
the  Jiffy  Game's  responsiveness.  The  automation  process  was  completed  in 
May  1975.  This  methodology  was  developed  principally  by  MAJ  Karl  .owe, 
assisted  by  LTC  Tom  Buff,  MAJ  Ken  Nash,  and  MAJ  Bob  Riddick,  and  was 
documented  in  July  1975  with  the  publishing  of  the  USACACDA,  SCORES 
"JIFFY"  War  Gaming  Methodology. 


In  the  fall  of  1975,  as  a quality  assurance  measure,  the  Jiffy  Game 
methodology  was  subjected  to  sensitivity  analysis.  A Jiffy  Game  improve- 
ment program  was  initiated  as  a result  of  the  analysis.  The  improvement 
program  consisted  basically  of  three  tasks.  First,  the  assessment  meth- 
odology needed  further  modification  and  improvement  in  certain  areas. 
Second,  the  capability  to  maintain  on  computer  files  a hierarchy  of  units 
consistent  with  the  overall  gaming  methodology  was  to  be  added  to  the 
Jiffy  Game.  Finally,  detailed  documentation  of  the  revised  methodology 
and  all  supporting  computer  programs  was  to  be  published.  This  report 
was  produced  as  a result  of  the  improvement  program  as  a portion  of  the 
Jiffy  Game  documentation. 

The  authors  of  this  report  wish  to  acknowledge  the  SCORES  war  gaming 
staff  of  the  Combined  Arms  Combat  Developments  Activity  (CACDA)  who  served 
as  consultants  during  the  preparation  of  this  report.  Special  thanks  are 
given  to  Mrs  Elizabeth  Etheridge,  who  served  as  technical  editor  for  this 
report,  and  Miss  Laura  B.  Weishaar,  who  typed  the  report. 
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ABSTRACT 


This  manual  is  one  of  a set  of  three  produced  to  document  the 
automated  features  of  the  Combined  Arms  Combat  Developments  Activity 
(CACDA)  "Jiffy"  war  gaming  process.  This  process  was  developed 
to  support  the  USATRADOC  Scenario  Oriented  Recurring  Evaluation 
System  (SCORES)  scenario  development  and  force  evaluation  efforts. 

This  report  contains  a discussion  of  the  manual  aspects  and  the  automated 
features  of  the  gaming  process  and  exemplifies  the  relationships  between 
them  through  a sample  run.  The  other  two  reports  in  the  set  are  the 
CACDA  Jiffy  War  Game  Technical  Manual  and  the  CACDA  Jiffy  War  Game 
Programmers  Manual.  The  technical  manual  consists  of  two  parts.  Part 
1 contains  the  methodologies  used  in  the  automated  routines  of  the 
Jiffy  Game,  the  computer  model  run  in  support  of  the  CACDA  "Jiffy" 
war  gaming  process,  and  an  unclassified  data  base.  Part  2 contains 
all  classified  data  and  its  sources  used  in  the  Jiffy  Game  during 
secure  production  runs.  The  programmer's  manual  consists  of  descriptions, 
logic  flow  diagrams,  and  the  FORTRAN  code  of  all  the  programs  and 
routines  associated  with  the  Jiffy  Game. 
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CACDA  JIFFY  WAR  GAME  USERS  MANUAL 


1.  PURPOSE  AND  SCOPE,  The  purpose  of  this  manual  Is  to  provide  a clear, 
concise  explanation  of  "how  to  game  Jiffy."  It  is  intended  to  provide 
information  to  personnel  familiar  with  war  gaming  but  not  familUr  with 
specific  Jiffy  procedures.  Although  the  SCORES  "Jiffy"  war  gaming 
procedure  at  Fort  Leavenworth  Incorporates  Air  Force  operations,  the 

Air  Force  operations  are  not  described  in  this  manual.  This  is  not  to 
imply  that  Air  Force  considerations  should  not  be  taken  into  account  in 
gaming,  but  rather  that  the  TACCOM  model  (reference  1)  now  runs 
separately  from  the  Jiffy  Game  and  is  Integrated  into  gaming  outside 
the  model. 

2.  JIFFY  DESCRIPTIONS. 

a.  General.  Jiffy  is  a two-sided,  computer-assisted,  open  war  game. 
Players  manipulate  forces,  using  maps  and  performance  indicators  to 
simulate  ground  combat.  Jiffy  is  an  Interactive  war  game  capable  of 
addressing  Indirect  fire,  armor/anti  armor,  armed  helicopter/air  defense, 
dismounted  Infantry,  and  minefield  play.  (If  the  security  condition 
warrants  Jiffy  can  be  run  in  a batch  mode;  however,  some  delay  in  response 
must  be  expected.)  Resolution  is  to  the  level  required,  normally 
battalion  for  Blue  and  regiment  for  Red.  A rate  of  advance  routine 
determines  time  to  advance  over  terrain  or  the  distance  advanced  in 

a given  time.  This  rate  influences  the  attrition  routines  by  defining 
the  duration  of  combat  along  specific  terrain  features. 

b.  The  Critical  Incident.  Jiffy  divides  a day  of  battle  into 
critical  incidents  (cl).  TRe  time  length  of  a Cl  is  variable;  it  should 
be  long  enough  to  permit  evaluation  of  selected  parameters  of  battle, 
yet  not  so  long  as  to  lose  the  significance  of  major  actions.  A good 
rule  of  thumb  is  to  have  CIs  4 to  6 hours  long.  This  length  gives  a good 
period  of  time  for  battles  to  take  place,  yet  allows  the  gamer  to 
influence  the  overall  battle  with  his  decisions.  If  the  action  is  light 
longer  CIs  may  be  used  in  order  to  decrease  the  real  time  to  battle  time 
ratio.  The  greater  the  influence  of  gamer  judgement,  the  shorter  will  be 
the  Cl  and  the  larger  the  real  time  to  battle  time  ratio.  Critical 
incidents  should  not  be  so  short  (less  than  2 hours)  as  to  imply  that 
Jiffy  is  a high  resolution  game,  which  it  is  not  designed  to  be.  From 
experience,  a 6-hour  critical  incident  for  a corps  level  battle  allows 
gamers  to  influence  the  battle  but  still  utilizes  the  computational 
ability  of  Jiffy  for  a relatively  quick  turnaround.  If  a division  or  lower 


is  to  be  investigated  CIs  might  be  slightly  shorter.  The  concept  of  a 
Cl  is  important  to  Jiffy  since  the  entire  game  is  basically  a sequence 
of  critical  incidents.  The  setup  of  each  critical  incident  follows  the 
same  procedures,  as  outlined  below. 

3.  PERSONNEL  REQUIREMENTS  AND  RESPONSIBILITIES. 

a.  General. 

(1)  A Jiffy  Game  requires  about  six  personnel,  at  least  four 
of  whom  should  be  military.  If  a game  Is  extremely  detailed,  additional 
manpower  may  be  required.  Personnel  are  required  In  two  main  categories, 
control  team  and  gamer  teams,  as  follows: 

(a)  Control  team. 

1^.  Chief  Controller  (military). 

2,  Assessment  Officer  (military), 

(b)  Blue  gamer  team, 

K Chief  gamer  (military). 

2,  Assistant  gamer. 

(c)  Red  gamer  team. 

U Chief  gamer  (military). 

''  Assistant  gamer. 

(2)  It  must  be  emphasized  that  this  gaming  staff  is  only  that 
required  to  play  the  game  interactively.  Analytical  support,  computer 
progranmlng  support,  and  secretarial  support  are  not  considered  here. 
Likewise,  If  a particular  field  of  military  expertise  is  needed,  It  must 
be  provided  from  an  outside  source. 

b.  Ch lef ■ CoQlrQ J_le,r . The  chief  controller  should  be  the  senior  person 
on  the  gaming  staff.  It  Is  his  responsibility  to  insure  that  the  gaming 
maintains  a logical  flow.  Since  Jiffy  Is  primarily  an  open  game,  the 
controller  must  Impose  constraints  on  the  Blue  and  Red  gamers  to  Insure 
their  actions  are  correct  In  a military  sense,  given  the  Intelligence 
Information  they  could  expect  to  possess.  Additionally,  the  chief  controller 
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must  Insure  that  actions  not  ccxnputerized  within  Jiffy  are  played 
logically.  For  example,  a unit  that  has  been  heavily  attrited  cannot 
be  brought  up  to  strength  itmiediately  and  committed  because  some 
organizational  time  is  needed.  It  is  the  chief  controller's  respon- 
sibility to  insure  that  the  game  produces  the  data  and  results  that 
are  needed  by  analytical  personnel  involved  in  a particular  study. 

The  chief  controller  has  overall  responsibility  for  the  performance 
of  the  entire  gaming  staff  to  insure  proper  preparation,  gaining,  and 
reporting. 


c.  Assessment  Officer.  The  assessment  officer  is  the  person  who 
actually  ptay's  'the  interactive  Jiffy  Game  on  the  terminal.  He  must  know 
both  the  logic  of  the  Jiffy  Game  and  the  tactical  feasibility  of  the 
maneuvers.  He  works  closely  with  both  the  chief  controller  and  the 
game'-s  to  insure  the  correctness  of  all  actions.  During  the  course  of 
a critical  incident,  he  works  directly  with  the  Red  and  Blue  gamers  on 
the  map  to  define  sectors  and  forces  in  that  sector.  It  is  the  assess- 
ment officer  who  determines  what  opposing  forces  face  each  other  in  the 
Jiffy  model.  He  then  inputs  the  forces  and  various  parameters  for  each 
sector  in  Jiffy.  The  assessment  officer  must  be  capable  of  making  the 
decisions,  such  as  disengagement  criteria,  that  are  called  for  during 
the  interactive  mode.  He  is  responsible  for  working  closely  with  Red  and 
Blue  gamers  to  Insure  the  teams  receive  the  proper  effects  front  conbat 
and  that  the  effectiveness  of  units  is  properly  maintained.  The  assess- 
ment officer  provides  a written  narrative  describing  the  action  that 
takes  place  in  each  critical  Incident,  The  chief  controller  is  responsible 
for  the  data  and  results,  but  it  is  the  assessment  officer  who  maintains 
the  actual  liaison  with  any  analytical  staff  to  insure  the  game  is 
accanplishing  Its  objectives. 


d.  Chief  Gamer  (Red  or  Blue).  The  chief  gamer  is  responsible  for 
orgenizin^  and  employing  his  "forces.  His  position  is  tiiat  of  co<ttmander 
of  his  forces  down  to  the  resolution  required.  He  ntust  le  able  to 
maintain  data  on  unit  effectiveness.  The  ciiief  gamer  develops  the  concepts 
and  provides  the  rationale  for  all  maneuvers.  He  insures  the  map 
situation  is  current.  With  the  assessment  officer  he  determines  the 
sectors  to  be  used  in  each  Cl.  The  chief  gamer  provides  a written 
narrative  of  his  concept  of  operation  and  the  rationale  behind  his  concept. 
He  should  have  a thorough  knowledge  of  the  tactical  doctrine  used  by  his 
forces . 


e.  The  Assistant  Gamer.  The  assistant  gamer  is  concerned  primarily 
with  f 0 View T ng  the  s t a tus  of  forces  on  his  side.  He  assists  the  assessment 
officer  with  the  initial  force  file  creation  for  the  game.  He  insures  the 
forces  in  each  sector  are  at  proper  strength  and  all  necessary  forces  are 
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included  in  a sector.  He  keeos  tiis  chief  gamer  informed  of  unit 
effectiveness  and  assists  in  maintaining  the  map  board.  He  is 
responsible  for  close  coordination  with  the  assessment  officer 
concerning  the  attrition  of  his  forces  during  a critical  incident. 

The  assistant  gamer  coordinates  the  replacement  policies  of  each  side. 

In  other  matters  he  assists  the  chief  gamer  as  directed. 

4.  METHODOLOGY. 

a.  General.  The  methodology  for  playing  a Jiffy  Game  may  be 

considered  in  three  major  phases:  preparation,  critical  incident 

gaming,  and  reports  and  results.  It  is  essential  to  maintain  a proper 
perspective  throughout  this  procedure  to  insure  Jiffy  is  not  used  for 
an  investigation  beyond  its  capability.  The  decisions  made  by  the 
commanders  are  a major  portion  of  the  entire  process  and  must  be 
reflected  effectively  in  each  critical  incident.  The  overall  sequence 
of  events  is  suimiarized  in  figure  1. 

b.  Preparation  Phase. 

(1)  The  preparation  phase  has  two  parts:  the  selection  and 
implementation  of  the  general  scenario,  and  the  preparation  for  the_ 
specific  game.  The  general  scenario  part,  although  it  is  a prerequisite 
for  any  Jiffy  Game,  is  usually  done  outside  the  gaming  staff.  It  includes 
Blue  and  Red  posture  at  the  start  of  the  game,  time  frame,  area  of 
operations,  weather,  and  objectives  of  the  game.  The  actual  preparation^ 
by  the  gamers  starts  with  the  receipt  of  the  general  scenario  and  objectives 
of  the  game.  In  the  initial  preparation  step  the  gamers  prepare  the  map, 
conduct  a terrain  analysis,  and  array  the  opposing  forces  on  the  map  as 
they  would  be  positioned  at  the  start  of  the  game.  While  the  chief  Blue 
and  Red  gamers  are  developing  their  general  concepts,  the  assistant 
gamers  under  the  direction  of  the  assessment  officer  create  the  TOE  force 
structure  files  on  the  terminal.  This  step  entails  creation  of  four 
files: 

(a)  Standard  reference  code  (SRC)  file.  In  this  file  weapons 
are  grouped  under  an  SRC.  These  SRCs  are  the  basic  building  block  for  the 
entire  force.  They  may  be  platoon,  company,  or  battalion  size  depending 
on  the  resolution  required.  A library  of  SRCs  has  been  built  and  is 
available  for  use,  if  appropriate. 

(b)  Unit  file.  In  this  file  units  are  built  based  upon  one 
or  more  SRCs.  The  units  will  generally  be  an  organizational  level  below 
the  resolution  desired.  This  gives  the  gamer  the  ability  to  play  part  of 
a unit  separate  from  the  parent  unit. 
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Figure  1.  Jiffy  war  gaming  process. 
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(c)  Parent.  utiiL  file.  In  this  file,  parent  units  are  built 
based  upon  one  or  more  units.  This  parent  unit  will  be  the  organization 
at  the  level  of  resolution  desired  (usually  battalion  for  Blue  and 
regiment  for  Red). 

(d)  Force  file.  The  force  file  is  a consolidation  of  the 
first  three  files.  This  file  is  processed  by  the  Jiffy  game  during  the 
gaming  of  a Cl.  It  contains  the  designation  of  each  unit  and  the  parent 
unit,  the  last  Cl  the  unit  was  involved  in  and  its  sector,  and  the  status 
of  all  the  weapon  systems  at  the  end  of  its  last  Cl.  Additionally,  the 
current  effectiveness  of  each  unit  is  maintained  in  this  file. 

(2)  A detailed  example  of  how  to  create  these  files  is  contained 
in  appendix  A.  The  force  file  is  the  file  from  which  optional  displays 
of  parent  units,  units,  and  their  strengths  are  derived.  When  the  loading 
of  the  starting  forces  is  completed,  the  actual  dynamic  gaming  of  Jiffy 
may  take  place. 

c.  Critical  Incident  phase.  The  critical  incident  phase  of  Jiffy  is 
the  major  portion  of  the  dynamic  gaming  process.  Reference  is  again  made 
to  figure  1.  The  Cl  phase  is  an  interactive  process  involving  the  four 
main  steps  indicated  in  figure  1;  rate  of  advance,  attrition  calculations, 
relative  effectiveness,  and  Cl  analysis.  The  critical  incident  analysis 
and  the  overall  concept  of  the  operation  determine  if  another  Cl  should  be 
run.  This  procedure  continues  until  the  game  reaches  some  predetermined 
termination  point.  The  gaming  usually  starts  with  a meeting  of  the  entire 
gaming  staff  in  a gaming  room,  with  the  map  and  overlays  showing  starting 
positions.  At  this  time  background  information  and  general  concepts  are 
briefed  for  both  sides.  The  remainder  of  this  subparagraph  describes  the 
steps  taken  each  time  a critical  incident  is  run. 

(1)  Sectors  defined.  The  chief  gamers  and  assessment  officer 
determine  from  the  map  board  and  the  commanders'  intentions  where  battles 
take  place  and  what  forces  are  involved.  This  process  in  essence  defines 
a sector.  The  entire  FEBA  may  be  subdivided  into  sectors,  or  sectors  may 
be  designated  only  in  areas  where  some  action  is  to  take  place.  The  Cl 
is  played  in  Jiffy  sector  by  sector  with  no  interaction  between  sectors. 

I The  sectors  may  vary  in  size  and  number  from  one  Cl  to  the  next.  Once 

the  sectors  have  been  defined  by  the  assessment  officer  and  chief  gamers, 
the  assistant  gamers  coordinate  with  the  assessment  officer  in  loading  the 
forces  for  that  sector.  Any  forces  that  would  affect  the  battle  and  are 
employed  in  that  sector  must  be  identified  to  include  infantry,  armor, 
artillery,  aviation,  and  air  defense  systems.  Specifically,  the  assistant 
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gamer  from  each  side  must  insure  that  the  forces  in  the  force  file  are 
true  and  correct  as  a result  of  any  replacements  that  might  have  arrived 
since  the  end  of  the  last  Cl.  If  not  he  must  access  the  force  file  and 
bring  a particular  unit  up  to  strength.  This  is  accomplished  interactively 
utilizing  the  file  handling  features  of  the  Jiffy  Game.  This  force  file 
update  should  be  done  prior  to  loading  forces  into  a sector  to  save  time. 

(2)  Force  loads.  After  the  terminal  has  been  logged  in,  and 
the  Jiffy  Game  accessed  (see  appendix  B for  this  procedure),  the  gamer 
reaches  the  DECISION  POINT.  The  interactive  game  centers  around  the 
DECISION  POINT.  Nine  options  are  available  to  the  gamer: 

. Load  forces  into  a sector. 

. Calculate  rate  of  advance. 

. Assess  combat. 

. Apportion  combat. losses  to  units. 

• Display  battle  statistics. 

• Display  weapon  arrays. 

. Add  SRCs  to  the  TOE  file. 

. Restart  at  a previously  gamed  Cl. 

. End  game  and/oh  update  HISTORY  file. 

Forces  may  be  assigned  to  a sector  by  assigning  the  parent  unit  (in  which 
case  all  units  in  that  parent  will  be  assigned)  or  by  assigning  spe’Cific 
units  from  a parent  unit.  The  ability  to  assign  part  of  a parent  unit  to 
one  sector  and  part  to  another  satisfies  the  condition  of  a parent  unit 
being  engaged  by  more  than  one  opposing  unit,  which  allows  it  to  be 
engaged  at  different  intensities  of  combat. 

(3)  Rate  of  advance, computed.  Aftir  the  forces  are  loaded  into 
a sector  the  rate  of  advance  must  be  computed  next.  The  questions  that 
the  assessment  officer  must  answer  are  listed  in  figure  B-A  of  the  example 
in  appendix  B.  This  routine  must  be  completed  prior  to  running  any 
assessment  routines.  Basically,  the  rate  of  advance  routine  calculates 

a total  firepower  ratio,  then  enters  a table  for  the  given  posture  of 
opposing  forces.  If  time  is  held  constant,  then  distance  advanced  is 
computed;  if  distance  is  held  constant,  then  time  is  computed.  This 
routine  is  essential  since  it  gives  the  closure  rate  of  ground  combat  for 
the  attrition  routines.  A detailed  explanation  of  the  logic  and  equations 
used  In  the  rate  of  advance  is  found  in  the  CACDA  Jiffy  War  Game  Technical 
Manual  (reference  2) . 

(4)  Attrition  calculated.  The  assessment  officer  is  concerned  with 

five  major  attrition  routines  when  playing  the  Jiffy  Game:  indirect  fire, 

armor/anti  armor,  mine  warfare,  attack  helicopter/air  defense  and  infantry 
assault.  A detailed  rationale  and  explanation  of  eacli  of  these  assessments 
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routines  may  be  found  in  the  CACDA  Jiffy  War  Game  Technical  Manual. 

The  descriptions  here  are  limited  to  an  explanation  of  the  interface 
that  takes  place  between  the  assessment  officer  and  the  program.  After 
the  rate  of  advance  has  been  calculated,  the  program  returns  to  the 
DECISION  POINT.  In  order  to  run  the  assessment  routines  a "3"  must  be 
entered  from  the  terminal.  The  program  then  cycles  through  the  assess- 
ment routines  in  the  following  order: 

. Indirect  fire. 

. Minefields. 

. Armor/ anti  armor. 

• Dismounted  infantry. 

• Attack  helicopter/air  defense. 

The  program  asks  the  gamer  if  he  wants  to  process  each  specific  routine. 

If  the  response  is  no,  that  routine  is  skipped,  If  the.  response  is  yes, 
further  questions  are  asked  by  the  program.  In  each  case  the  questions 
require  the  input  of  parameters  that  influence  the  attrition  routines. 

At  the  end  of  each  attrition  routine  there  is  the  option  of  deleting  the 
losses  '.^rom  the  weapon  system  array  in  that  sector.  If  everything  has 
progressed  satisfactorily  the  losses  may  be  subtracted,  and  the  program 
advanced  to  the  next  assessment  routine.  If  for  some  reason  the  assess- 
ment officer  wishes  to  replay  that  specific  attrition  routine,  he  would 
not  subtract  the  forces.  He  must  then  return  to  the  beginning  of  the 
cycle,  not  playing  those  assessment  routines  already  satisfactorily 
played,  until  he  again  reaches  the  routine  he  wished  to  replay  and 
continue  from  there.  A detailed  example  of  the  assessment  questions 
is  included  in  appendix  B,  This  process  is  the  heart  of  the  interactive 
games.  The  assessment  officer  must  insure  that  the  parameters  put  into 
the  game  accurately  reflect  the  terrain,  posture,  and  tactics  of  the 
force  Involved.  His  military  judgement  and  coordination  with  both  team 
chiefs  is  needed  to  make  such  decisions  as  when  to  pull  out  of  a defensive 
position,  or  what  Intensity  of  artillery  is  being  fired.  Close  coordination 
between  the  assessment  officer  and  chief  controller  may  be  required  here  to 
insure  that  reality  is  represented  as  closely  as  possible. 

(5)  Losses  apportioned.  Once  the  attrition  routines  have  been 
played,  the  game  returns  to  the  DECISION  PUINI.  In  order  to  apportion 
the  cotnbat  losses  from  the  sector  to  the  proper  forces  in  the  force  file, 
a "4"  must  be  entered.  After  the  "4"  has  been  entered,  the  combat 
intensity  must  be  entered  for  each  unit.  This  combat  intensity  determines 
the  amount  of  losses  apportioned  to  each  unit.  If  one  unit  was  in  combat 
less  than  another  during  the  Cl,  it  incurs  a smaller  proportion  of  losses. 
The  specific  entries  for  given  conditions  of  combat  are  as  shown  in  table  1. 
The  routine  distributes  the  losses  to  the  units,  and  the  gainer  has  the 
option  of  seeing  the  new  force  file  at  the  completion  of  the  routine.  An 
example  of  this  routine  is  in  figure  B-11  of  appendix  B, 
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Table  1.  Combat  intensity  entries  for  apportionment  routines. 


ENTER 


FOR  THIS  STATUS 


0 

1 

2 

3 

4 

5 


Uncommitted  units 
Units  outside  of  direct  fire 
Reserve  units  committed  late 
Units  oii  perimeter  of  MBA 
Units  in  Main  Battle  Area 
Units  Hit  by  TACAIR 


(6)  Unit  effectiveness  determined.  During  the  loss  apport’.onment, 
the  new  relative  unit  effectiveness  of  each  unit  is  computed.  Simply, 
the  unit  effectiveness  of  a unit  is  the  ratio  of  its  present  firepower 
score  to  the  firepower  score  the  unit  started  with.  This  computation, 
output  on  the  Unit  Status  portion  of  the  STATS  file  (see  appendix  C), 
combined  with  the  gamer's  knowledge  of  the  task  organizations  should 
be  sufficient  to  provide  a base  for  the  military  judgment  used  in  decisions 
made  during  the  analysis  of  the  Cl. 

d.  Reports  and  Results  Phase.  The  final  phase  of  the  Jiffy  War  Gaming 
process  is  the  resuTts  presented  and  the  reports  produced  from  those 
results. 


(1)  Results.  For  each  sector  there  are  two  types  of  information 
recorded.  First,  each  unit  gamed  in  that  sector  has  a record  of  losses 
and  current  remaining  status  of  weapons.  These  unit  displays  also  include 
the  relative  effectiveness  of  each  unit.  Each  unit  is  reported  separately 
and  the  aggregated  status  of  the  parent  unit  is  reported  also.  Second, 
each  sector  has  statistical  tables  showing  loss  by  source  of  loss,  loss 
and  damage  distribution,  ammunition  expenditure,  and  killer  victim  tables. 
Additionally,  these  tables  are  aggregated  for  an  entire  critical  incident. 

A detailed  description  of  the  output  from  Jiffy  is  given  in  appendix  C. 

(2)  Reports.  The  content  of  the  game  report  must  by  its  very 
nature  vary  depending  upon  the  objective  of  any  game.  However,  there  are 
certain  areas  that  the  report  should  contain  as  a minimum.  There  should 
be  a narrative  description  of  the  game  as  it  developed.  This  is  usually 
the  assessment  officer's  portion  of  the  report.  The  rationale  for  gamer 
tactics  and  organizations  is  input  by  the  chief  gamers.  Finally,  insights 
into  force  structures  (strength  and  deficiencies)  should  be  reported.  This 
last  area  may  be  expanded  or  contracted  depending  upon  the  purpose  of  the 
game. 
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APPENDIX  A 

SAMPLE  RUN  OF  FORCE  FILE  GENERATION  PROCESS 


A-1.  PURPOSE  AND  SCOPE.  The  purpose  of  this  appendix  Is  to  provide 
the  gamer  and  the  assessment  officer  a step  by  step  procedure  for  the 
creation  of  a file  of  forces  suitable  for  processing  by  the  Jiffy  Game. 

An  example  of  each  of  the  programs  used  to  generate  such  a force  file 
Is  presented  and  discussed,  in  turn,  below. 

A-2.  GENERAL.  Basically  three  files  are  created  to  define  units,  and 
one  file  Is  created  on  which  the  data  of  the  other  three  files  are 
consolidated.  The  SRC  (standard  reference  code)  file,  the  UNIT  file, 
and  the  PARENT  file  are  the  three  files  used  to  define  the  weapons  of 
SRCs,  build  units  from  SRCs  and  develop  higher  echelon  parent  units. 

The  FORCE  file  is  the  file  that  contains  all  the  information  of  the 
three  files  formatted  for  processing  in  the  Jiffy  Game.  Initially,  some 
empty  files  are  created  and  given  names.  In  the  example  presented  here, 
the  files  are  SRCFILE,  UNITFILE,  PARENTFILE,  and  FORCEFILE.  To  facilitate 
processing,  interactive  ''call''  files  have  been  created  that  contain  the 
control  cards  necessary  to  attach  the  proper  files  and  execute  the  programs. 

In  the  following  sample  runs,  the  alpha-character  responses  input  by  the 
gamers  are  smaller  than  the  letters  in  questions  displayed  by  the  Jiffy 
Game  program.  Note,  however,  that  there  is  no  difference  between  a 
gamer  response  and  a computer  display  for  numerals. 

A-3.  "CALL"  FILES.  The  sample  runs  presented  in  the  following  paragraphs 
are  initiated  by  the  use  of  "call"  files.  Listings  of  the  five  "call" 
files  used  for  processing  the  runs  in  this  document  are  given  in  figure 
A-1.  Each  of  these  files  contains  control  statements  that  accomplish  three 
basic  requirements  for  running  one  of  the  programs.  The  requirements  are: 

1)  connects  input  and  output  as  required  for  interactive  processing,  2) 
attaches  the  program  and  all  the  files  the  program  operates  on  (a  data 
file  must  be  attached  as  CLOATA  before  the  "call"  fiWs  for  the  FORCE 
program  or  the  Jiffy  Games  are  executed),  and  3)  executes  the  program, 
the  commands  contained  in  the  "call"  files  can  be  entered  individually 
from  the  console.  It  should  be  noted,  in  fact,  that  some  operating  systems 
may  not  allow  "call"  files,  in  which  case  the  commands  would  have  to  be 
input  separately.  All  commands  and  I-O  procedures  demonstrated  in  this 
document  are  for  the  SCOPE  3.4.4  operating  system  presently  in  use  on  the 
Control  Data  Corporation  (COC)  6400/6500  multiprocessor  computer  at  Fort 
Leavenworth,  Kansas.  One  point  to  be  emphasized  is  that  the  local  file 
names  for  the  force-type  files  must  be  exactly  as  shown  in  figure  A-1  when 
one  of  the  programs  Is  being  run.  For  example,  to  run  the  Jiffy  Game  program, 
the  FORCEFILE  must  be  attached  as  TAPE5S,  the  SRCFILE  as  TAPES,  and  the 
HISTORYFILE  as  TAPES. 


p.ur.i:-;n:i:  r c u.: 

COririLCT^  I MPUTj  OUTPUT. 

RTTRCHj  LGO?  SRCBirU  iri=SCORESjSN=SYScii  MR=1 . 
RTTflCH  ? TRPE9  SRCF I LE  j I H=SCOF£S  j SN= J I FPF  . 
LGO. 


ruMUHiT  nut: 
i:ijMr<ECTj  INPUT  j OUTPUT. 

RTT  RCH ' LGO  j Ut  1 1 TE I N ••  I D=SCORES  j Sh=bYbc  > MR=  1 . 
RTTflCH j TRPE9 ? SRCF I LE > I E=SCOF£S  j SN= J 1 FPF . 
ATTACH? TflPElO? UHITFILE?  IIi=Sa:iRES> SN=JIFPF . 
LGO. 


r.ur  jPHRErrr  k i utr. 

CufirCCT?  INPUT?  OUTPUT. 

A7  TflCH?  LGO?  PRRENTE IN? I D=SCORES  ? SN=SYS£  ? NR~ 1 . 
ATTACH?  T APE  1 1 ? PAREN7  F I LE? I H=SCORES  ? SN= J IFPF . 
ATTACH  ? TAPE  1 0 ? UN  I TF I LE  ? I D=SO:tRES  ? SN= J I FPF . 
LGO. 

RUNFaftCt:  FILE 

i:CNNECT?  iNf-'UT?  OUTPUT. 

ATTACH?LGO?  FORCEEIN? ID=SCORES?  SN=SYSS?  MR=1 . 
ATI  ACH?  TAPE6?  PFlRENTF  I LE  ? I D=9::ORES  ? SN= J I FPF . 
RTTACH?TAPE7?  Uf  IITFILE?  in=SCCf::ES?  SN--=JIFPF. 

AT TACH ? TAPES ? SRCF I LE  ? I E^SCOFES  ? SN= J I FPF . 
ATTACH  ? TRPE9  ? FORCEF I LE  ? I D^SCORES  ? SN= J I FPF . 
LGO. 


RUh4..ixrF^t'  I--  xur. 

1 i.NNFXT?  INPUT.  OUTPUT. 

ATTACH?  JIFF',’?  JIFBIN?  I D^SCORES.  I'lR^l  ? SN=JIFPF  . 
A T T RCH ? TRPE9  ? SRCF I LE  ? I D=SCOF£S  ? SN= J I FPF . 
ATTACH?  TAPE5E.  ? FORCEF  I LE  ? I H=SCORES?  SN=  .J  IFPF . 
AT  TACH  ? TRF'E  . H I ST  OR’f'F  1 1.  E ? I D=SCORES  ? S.N== -J  I K PF . 
JIFFY. 


Figure  A-1.  "Call"  files  for  programs  of  the  Jiffy  Game. 


Best  Available  Copy 


A-4.  CREATION  OF  SRC  FILE.  The  SRC  file  is  intended  to  be  developed 
in  a manner  consistent  with  the  US  Army's  concept  of  Tables  of  Organi- 
zation and  Equipment  (TOE).  Each  record  consists  of  a name  (SRC)  and 
the  type  and  quantity  of  weapons  in  the  corresponding  organization. 

A maximum  of  22  different  types  of  weapons  can  be  entered  in  a given 
SRC.  An  exOTple  of  a run  of  the  SRC  program  is  presented  in  figure 
A-2.  In  this  example,  consider  item  code  1 to  be  personnel,  item  code 
2 to  be  tanks,  and  item  code  3 to  be  APCs.  As  shown  in  figure  A-2,  the 
run  is  initiated  by  the  gamer  through  the  entry  of  the  "call”  command. 
This  attaches  cycle  1 of  two  files  (SRCFILE  and  SRCBIN,  a binary  file  of 
the  compiled  SRC  program)  and  executes  the  program.  Next,  as  shown  in 
figure  A-2,  an  "x"  is  entered  to  display  all  valid  action  codes.  After 
this,  a Blue  tank  platoon  is  entered  onto  the  SRC  file  by  entering  an 
"a"  action  code,  entering  the  name  (1  to  10-character  alphanumerics)  for 
the  Blue  tank  piatoon  SRC  (BTANKPLT),  and  entering  the  type  and  quantity 
of  each  weapon  in  the  Blue  tank  platoon.  In  this  instance,  20  personnel, 
5 tanks,  and  1 APC  are  entered.  Figure  A-2  also  contains  examples  ov 
the  other  actions  available  to  the  gamer.  The  review  action  simply 
displays  the  type  and  quantity  of  weapons  in  a specific  SRC.  The  change 
action  allows  the  gamer  to  modify  the  quantities  of  one  or  more  of  the 
weapons  in  a given  SRC.  The  delete  option  renoves  either  an  entire  SRC 
from  the  SRC  file  or  specific  weapons  from  a given  SRC.  The  list  action 
displays  all  the  SRCs  with  their  weapons  on  the  SRC  file.  The  run  h 
terminated  by  specifying  an  "e"  action.  For  the  sample  run  of  other 
programs,  which  follows,  the  following  SRCs  have  been  put  onto  the  SRC 
file  with  the  proper  Jiffy  Game  item  codes: 

a.  6AHC0  - Blue  attack  helicopter  company. 

b.  BARTYBAT  - Blue  artillery  battery. 

c.  8ARTYBNHQ  - Blue  artillery  battalion  headquarters. 

d.  8MECHPLT  - Blue  mech  platoon. 

e.  BTANKPLT  - Blue  tank  platoon. 

f.  BTAhKCOHQ  Blue  tank  company  headquarters. 

g.  RARTY6N  - Red  artillery  battalion. 

h.  RHCCHCO  - Red  mech  company. 

i.  RTANKBNCP  - Red  tank  battalion  command  post. 

j.  RTANKCO  - Red  tank  company. 
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Figure  A-2.  Sample  run  of  SRC  program. 
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A-5.  UNIT  FILE  CREATION.  Once  the  gamer  has  specified  all  the  SRCs 
necessary  to  initialize  the  scenario,  a file  of  the  combat  units  may 
be  built.  This  is  accomplished  through  the  execution  of  the  UNIT  program. 
A sample  run  of  the  UNIT  program  is  presented  in  figure  A-3.  As  can 
be  seen  from  the  sample  run,  the  process  to  build  units  from  SRCs  is 
similar  to  that  of  the  SRC  program.  Again,  the  gamer  initiates  the  run 
through  the  Interactive  “call"  command,  which  attaches  three  files 
(SRCFILE,  UNITFILE,  and  UNITBIN,  the  UNIT  program  compiled  binary  file) 
and  executes  the  program.  The  "x"  action  code  entry,  as  before,  displays 
the  valid  action  codes  available  to  the  gamer.  The  sample  run  demon.* 
strates  the  addition  of  two  units  to  the  UNIT  file:  a Blue  armor  company 

team  consisting  of  two  tank  platoons,  a mech  platoon,  and  a tank  company 
headquarters;  and  a reinforced  Red  tank  battalion  consisting  of  three 
tank  companies,  a mechanized  rifle  company,  and  a tank  battalion  command 
post.  The  other  actions  of  the  UNIT  program  are  virtually  identical  to 
those  of  the  SRC  program  exemplified  In  figure  A-2.  A listing  of  all 
units  on  the  UNITFILE  (action  type  1)  has  been  Included  In  figure  A-3. 
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Figure  A-3.  Sample  run  of  UNIT  program  (continued  next  page). 
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A-6.  PARENT  UNIT  FILE  CREATION.  The  PARENTFILE  is  a file  on  which  the 
units  defined  on  the  UNITFILE  are  grouped,  if  desired,  into  higher 
echelon  organizations.  A sample  run  of  the  PARENT  program  is  given  in 
figure  A-4.  As  before,  the  "call"  command  is  entered  to  attach  the 
UNITFILE,  PARENTFILE,  and  PARENTBIN  (the  binary  compiled  file  of  the 
PARENT  program)  and  to  execute  the  program.  An  "x"  action  type  entry 
displays  the  valid  action  codes.  The  sample  run  demonstrates  the  entries 
of  two  common  variations  of  parent  unit  groupings.  The  first  parent  unit 
entered  was  for  Bl-IA.  In  this  example,  the  parent  unit,  a battalion,  is 
composed  of  the  companies:  BA/l-lA,  BB/l-lA,  and  BC/l-lA,  The  second 
example  is  for  B7AVN,  which  has  only  one  subordinate  unit  in  it.  A "1" 
action  listing  of  the  parent  unit  organizations  is  also  provided  in 
figure  A-4.  As  in  the  UNIT  program,  the  other  valid  action  types  are 
similar  to  those  of  the  SRC  program,  and  example  runs  may  be  found  in 
figure  A-2. 
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I Figure  A-4.  Sample  run  of  PARENT  program  {continued  next  page). 
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Figure  A-4.  Sample  run  of  PARENT  program  (concluded). 
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A-7.  FORCE  FILE  CREATION.  The  FORCEFILE  is  actually  a consolidation 
of  the  information  contained  on  the  other  three  files  in  a format 
suitable  for  processing  in  the  Jiffy  Game.  A sample  run  of  the  FORCE 
program  is  presented  in  figure  A-5.  The  interactive  "call"  command, 
which  for  the  FORCE  program  attaches  five  files  (SRCFILE,  UNITFILE, 
PARENTFILE,  FORCEFILE,  and  FORCEBIN,  the  FORCE  program  compiled  binary 
file)  and  executes  the  program,  is  preceded  by  an  attach  of  the  Jiffy 
Game  random  access  data  base,  which  is  the  unclassified  version  for 
this  example.  The  first  entry  in  the  FORCE  program  Identifies  the  force 
into  which  the  parent  units  are  to  be  initialized.  The  force  entry  must 
be  either  "b",  denoting  the  Blue  force,  or  "r"  denoting  the  Red  force. 
After  the  force  type  specification,  the  valid  actions  are  displayed 
with  an  "x"  action  entry.  Next,  since  a "b"  was  entered  for  force  type, 
all  parent  units  entered  are  for  Blue.  Following  the  entry  of  each 
parent  unit,  the  user  assigns  a unit  effectiveness  to  every  subordinate 
unit  within  the  designated  parent.  (Normally  the  entry  is  100;  however, 
if  a game  is  being  started  with  the  assumption  that  some  previous 
attrition  has  taken  place,  then  the  unit  effectiveness  may  be  less.) 

This  procedure  initialUes  the  units  onto  the  FORCEFILE.  Note  that  during 
this  process,  the  computer  displayed  some  extraneous  information  in  the 
sample  run  after  the  relative  (unit)  effectiveness  specifications  for 
BC/i-lA  and  B3-11FA.  This  information  is  displayed  each  time  one  of  the 
indexed-sequential  files  is  automatically  extended  by  the  computer's 
operating  system.  After  the  initialization  of  the  Blue  force  onto  the 
FORCEFILE,  an  “1"  option  is  entered  to  display  all  the  units  and  parent 
units  with  their  associated  weapon  systems.  As  shown  in  the  display  in 
figure  A-5,  all  the  units  are  in  sector  0 of  an  undefined  critical 
incident.  These  game  variables  are  set  during  the  actual  processing  of 
the  Jiffy  Game.  The  "1"  action  automatically  ends  the  Blue  (or  Red) 
session  of  the  FORCE  program  and  returns  it  to  the  point  in  the  program 
that  defines  the  type  force,  otherwise  the  session  is  ended  with  the  "e" 
action.  The  Red  session  is  initiated  with  an  “r"  force  specification. 

The  Red  units  are  defined  and  listed  the  saine  as  the  Blue  forces.  The 
FORCE  program  is  terminated  through  the  specification  of  an  "e"  action. 
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Figure  A-5.  Sample  run  of  FORCE  program  {continued  ne*t  page} 
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Figure  A-5,  Sample  run  of  FORCE  program  (continued). 
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Figure  A-6.  Sample  run  of  FORCE  program  (continued). 
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APPENDIX  B 

SAM>IE  RUN  or  THE  JIFFY  GAME 


APPENDIX  B 


SAf^PLE  RUN  OF  THE  JIFFY  GAME 


8-1.  PURPOSE  AND  SCOPE.  The  purpose  of  this  appendix  is  to  provide 
the  user  a step  by  step  procedure  for  playing  the  interactive  Jiffy  Game. 
Due  to  the  security  classification  of  a portion  of  the  Jiffy  Game  data 
base  (CLDATA),  the  program  has  been  developed  with  the  capability  to  be 
run  both  interactively  and  batch  for  secure  processing.  The  example 
presented  in  this  appendix  is  for  an  unclassified  interactive  run. 

The  modifications  necessary  for  batch  processing  are  presented  in  appendix 

0. 


8-2.  GENERAL.  The  computer  performs,  basically,  two  major  tasks  in  the 
"Jiffy"  war  gaming  process.  First,  it  is  used  for  bookkeeping  in  the 
sense  that  it  keeps  track  of  the  units  being  gained  and  updates  their 
status  for  attrition  suffered  in  con^oat  and  other  changes  to  their  status, 
which  may  be  entered  manually.  Second,  the  computer  is  used  to  perfortn 
the  attrition  calculations  and  keep  a record  of  vital  combat  statistics. 

8-3.  INITIATION  OF  tHE  GAME.  After  all  the  units  to  be  entered  into 
combat  have  been  initialized  on  the  FORCEFILE  (see  appendix  A),  and  an 
empty  history  file  (HISTORYFILE)  has  been  created,  tne  user  is  ready  to 
begin  processing  the  Jiffy  Game.  Once  again,  to  reduce  the  number  of 
control  cards  and  to  ensure  that  the  proper  files  are  attached,  a "call" 
file  (RUNJIFFY)  has  been  prepared.  Execution  of  the  "call"  file  attaches 
four  files  (FORCEFILE,  SRCFILE,  HISTORYFILE,  and  JIFBIN,  the  binary 
compiled  file  of  the  Jiffy  Game  program)  and  executes  the  program. 

Before  the  "call"  file  is  entered  by  the  user,  however,  the  data  file 
(CLOATA)  must  be  attached.  Figure  B-1  contains  an  exwple  of  this  process 
and  the  initial  user  responses  necessary  to  process  the  game.  In  this 
example,  the  unclassified  data  base  (UNDATA)  has  been  attached  as  CLDATA. 
the  game  begins  by  asking  the  user  if  he  wishes  to  see  instructions.  Any 
response  other  than  "n"  to  this  question  dHplays  the  user  instructions 
shown  in  figure  B-1.  After  the  instructions  have  been  displayed,  or  not 
as  the  case  may  be,  the  user  is  asked  to  specify  the  purpose  of  the  ryn. 

The  entry  of  '"T"*,  reveals  that  this  user  response,  to  specify  the  purpose 
of  the  run,  selects  the  mode  (batch  or  interactive)  under  which  the  garsse 
is  to  be  run.  Since  Ih is  example  is  to  be  of  an  interactive  run,  a "‘2" 
is  entered.  This  brings  the  program  logic  to  the  DECISION  POINT.  The 
entry  of  '"T"*  displays  all  the  alternative  courses  of  action  available  to 
the  user  at  this  point  as  depicted  in  figure  B-1, 
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Figure  B>1.  Initiation  of  sample  Jiffy  Game  run. 


B-4.  FORCEFILE  MANIPULATION.  Other  than  performing  the  basic  file 
handling  features  of  the  Jiffy  Game,  which  are  the  restart  capability 
and  the  HISTORYFILE  update  (DECISION  POINTS  8 and  9,  respectively),  the 
units  involved  in  the  combat  to  be  gamed  must  be  loaded  into  their 
respective  sectors  before  any  Jiffy  Game  assessments  can  be  processed. 

The  units  on  the  FORCEFILE  are  loaded  into  sectors  by  the  procedures 
available  to  the  user  through  DECISION  POINT  1.  Figure  B-2  contains 
examples  of  these  file  manipulation  options.  After  entering  a "1“  at 
the  DECISION  POINT,  the  user  is  asked  to  input  the  critical  incident 
mnemonic  identifier  (1  to  10  alphanumeric  characters)  and  the  sector 
number  to  be  gamed.  In  the  example,  these  are  entered  as  "TESTl"  and 
"I",  respectively.  As  seen  in  figure  B-2,  a '"T"'  entered  at  OPTION 
displays  the  force  file  manipulation  options  available  to  the  user. 

a.  Since  at  this  point,  the  user  may  wish  to  see  the  units  on  che 
FORCEFILE,  the  display  option  is  chosen  (OPTION  6).  A '“T"'  entered  for 
the  type  of  display  lists  for  the  user  the  four  types  of  displays  'or 
units  on  the  FORCEFILE.  For  reasons  stated  above,  a "I"  is  entered, 
and  the  indicated  type  of  display  is  presented. 

b.  As  seen  from  the  display,  the  units  defined  in  the  processes 
presented  in  appendix  A are  present  at  the  unit  effectiveness  (EFF.i 
initialized,  with  the  addition  of  an  extra  unit  (INITIAL).  This  unit 
is  actually  an  extraneous  record  written  on  the  FORCEFILE  at  its 
creation  and  may  be  deleted  from  the  FORCEFILE,  as  shown,  by  exercising 
OPTION  7.  The  "all”  entry  under  this  option  perfoms  the  deletion  of 
all  records  on  the  FORCEFILE  whose  parent  u?;it  is  INITIAL. 

c.  The  display,  printed  by  the  dispv':>y  option  above,  shows  that 

the  actual  units  are  still  in  sector  0 of  an  unspecified  critical  incident. 
Any  of  these  units  may  be  loaded  in'‘o  the  specified  critical  incident 
(TESTl)  and  sector  (1)  through  OPTiJN  1.  The  example  unit  loads  in 
figure  8-2  illustrate  several  variations  of  the  load  option.  The  load 
for  Bl-IA  specifies  that  all  units  attached  to  Bl-IA  are  to  be  loaded 
into  the  specified  critical  incident  and  sector.  "ALL"  is  specified  in 
this  instance  to  load  all  three  companies  of  Bl-lA  with  one  entry.  Another 
way  of  accomplishi«ig  a similar  load  would  be  to  load  each  company  separately. 
An  example  of  this  type  of  load  is  illustrated  by  the  load  for  B/AVN. 

Only  c?ne  unit  (B7AVNC0)  is  attached  to  87AVN.  However,  in  this  case,  the 
actual  subordinate  unit  designation  is  specified  instead  of  "all". 

d.  After  all  the  unit  loads,  an  example  of  OPTION  2,  the  remove 
option,  is  presented.  This  option  allows  the  user  to  remove  a unit 
from  a sector  into  which  it  was  loaded.  When  a unit  is  removed  fro<a  a 
sector,  I is  loaded  into  sector  0 of  the  specified  critical  incident. 


(j.  An  example  of  Llie  option  that  enables  tlie  user  to  create  units 
during  the  game  is  also  included  in  the  sample  run.  The  create  option, 
OPTION  3,  provides  two  ways  of  creating  units.  First,  the  user  is 
allowed  to  use  SRCs,  which  exist  on  the  SRCFILE,  to  define  the  subunit 
organizations  of  the  unit  being  created.  An  example  of  this  procedure 
has  not  been  included  in  the  sample  run,  because  it  is  similar  to  the 
procedures  presented  in  appendix  A,  paragraph  A-4.  Second,  the  user  is 
allowed  to  create  a unit  through  the  specification  of  the  types  and 
quantities  of  weapon  systems  contained  in  the  unit.  An  example  of  this 
type  of  create  is  included  in  figure  B-2. 

f.  An  example  of  OPTION  4,  the  option  that  provides  the  user  the 
capability  to  adjust  (add  or  subtract)  weapons  systems  in  a unit,  is 
also  presented,  which  changes  the  quantity  of  weapon  type  2 from  I4 
to  23  in  unit  B A/1-23A. 

g.  An  example  of  OPTION  5 is  also  included.  This  option  is  used 
to  attach  a subordinate  unit  to  a new  parent  unit. 

h.  After  the  above  operations  are  performed,  the  FORCEFILE  is  once 
again  displayed.  As  can  be  seen  from  the  display  in  figure  B-2,  the 
INITIAL  record  is  gone  and  all  the  units,  with  the  exception  of  Bl-IA, 
are  in  sector  1 of  critical  incident  TEST!.  Bl-IA  appears  not  to  be 
loaded  because  only  three  of  its  four  units  were  loaded,  and  the  unit 
not  loaded  happened  to  be  the  last  logical  unit  on  the  FORCEFILE  for 
Bl-IA.  Since  a type  1 display  only  prints  the  parent  unit,  the  sector 
and  critical  incident  in  which  it  is  located  is  taken  to  be  that  of  its 
last  unit.  A type  3 display,  as  shown  in  the  example,  confirms  that 
three  of  the  units  of  Bl-IA  were  loaded  as  specified. 

i.  The  options  of  DECISION  POINT  1 are  always  concluded  with  the 
specification  of  OPTION  0.  This  option  fills  the  weapon  system  arrays, 
which  are  used  in  the  Jiffy  Game  assessment  routines,  with  the  weapons 
of  the  units  that  have  been  loaded  into  the  sector  and  critical  incident 
being  gamed. 
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Flgure  B-2.  Options  for  FORCEFILE  manipulation  (Continued 
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Figure  B-2.  Options  for  FORCEFILE  manipulation  (continued). 
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B-5.  RATE  OF  ADVANCE.  After  all  units  for  each  force  have  been  loaded 
into  a sector,  the  rate  of  advance  and,  subsequently,  the  combat 
assessments  for  that  sector  can  be  processed.  It  should  be  noted  here 
that  neither  rate  of  advance  nor  combat  assessments  need  be  done 
iimed lately  after  the  units  have  been  loaded  in  a sector.  Most  users 
of  the  Jiffy  Game  to  date  have  found  that  it  is  more  efficient  to  load 
the  units  into  all  sectors  for  a particular  critical  incident  (Cl) 
prior  to  running  any  rate  of  advance  or  assessment  routines. 

a.  The  example  given  in  figure  B-2  demonstrated  the  loading  of 
units  into  sector  1 of  a Cl  identified  as  TESTl.  The  weapon  system 
array  created  by  selecting  OPTION  0 (zero)  is  displayed  by  entering  a 
'*6“  at  DECISION  POINT  as  shown  in  figure  B-3.  This  array  is  used  in  the 
rate  of  advance  calculations;  the  FORCEFILE  itself  is  not  operated  on 
during  this  portion  of  the  Jiffy  Game. 

b.  Figure  B-4  is  a sample  run  of  the  rate  of  advance  routine,  which 
is  initiated  by  entering  a "2“  at  DECISION  POINT.  Where  appropriate,  a 
*'*T“'  has  been  entered  to  display  the  input  options  availabU  to  the  user. 
The  responses  given  In  this  example  are  not  intended  to  portray  realistic- 
ally any  particular  battlefield  situation  but  have  been  selected  In  such 

a way  that  all  possible  Inputs  that  might  be  required  are  shown.  Input 
of  an  attacker  posture,  for  example.  Is  not  asked  for  whenever  a "1“ 
(meeting  engagement),  a “E**  (delay),  or  a “3*  (withdraw)  is  entered  for 
the  type  of  engagement.  Some  Inputs  In  rate  of  advance  set  parameters 
that  determine  Input  requirements  or  limitations  In  the  combat  assessment 
portion  of  the  game.  The  minefield  emplo/nent  response  given  in  this 
routine,  for  Instance,  determines  whether  or  not  minefield  assessroentr. 
can  be  made.  The  Inputs  made  In  this  routine  serve  primarily  to  represent 
the  environmental  and  military  conditions  of  the  battlefield.  The  meaning 
and  significance  of  these  parameters  to  the  Jiffy  Game  methodology  are 
documented  In  the  Jiffy  Game  Technical  Manual  (reference  2),  Not  demon- 
strated In  the  sample  run  Is  the  result  of  entering  the  rate  of  advance 
routine  when  the  defending  force  has  no  weapons  in  the  array.  Should  this 
occur,  an  error  message  is  displayed  just  after  the  Blue  air  threat  input 
Is  made,  and  the  program  returns  Immediately  to  the  DECISION  POINT  during 
an  Interactive  run.  (In  a batch  processing  mode,  execution  of  the  prograw 
Is  terminated.) 
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Figure  B-3.  Initial  weapon  system  array  for  sample  runs. 
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Figure  6-4.  Sample  run  of  rate  of  advance.  (Continued 
next  page.} 
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Figure  B«4.  $Mple  run  of  rate  of  advance  (concluded). 
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B-6.  COMBAT  ASSESSMENTS.  Following  a successful  run  of  the  rate 
of  advance  routine,  the  combat  assessments  can  be  initiated  by  entering 
a ''J“  at  the  OtCISION  POINT.  Losses  can  be  determined  for  six  different 
types  of  combat  in  the  Jiffy  6a«iie.  Tliese  combat  types,  in  the  order 

Processed,  are:  TACAIR,  2)  indirect  fire,  3)  mines,  4)  armor/ant iannor, 

) infantry,  and  6)  attack  helicopter/air  defense.  As  in  the  rate  of 
advance  calculations,  all  combat  losses  assessments  are  based  on  the 
weapon  system  array  displayed  in  figure  B-3.  A sample  run  of  each  combat 
assessment  is  presented  and  discussed  in  the  following  subparagraphs. 

a.  TACAIR.  When  a “3“  is  input  for  the  DECISION  POINT,  the  first 
combat  losses  to  be  addressed  are  TACAIR.  The  Jiffy  Game  does  not  make 
the  actual  attrition  calculations  for  TACAIR  combat;  a model  called 
TACCOM  (see  reference  1),  developed  and  run  by  the  US  Air  Force,  is 
used  to  determine  TACAIR  combat  losses.  The  Jiffy  Game  simply  acceots 
as  direct  input  the  cumulative  losses,  by  weapon  type,  output  from  tne 
TACCOM  model  as  illustrated  in  figure  B-5.  The  net  result  of  this  sample 
run  is  the  loss  (subtraction)  of  one  weapon  type  ZZ  from  the  Blue  force. 
Incorrect  entries  have  been  Input  to  demonstrate  more  clearly  the  correct 
form  of  responses  needed.  When  all  TACAIR  losses  have  been  entered,  the 
program  proceeds  to  a subsequent  combat  assessment  routine  with  no 
intervening  DECISION  POINT. 

b.  Indirect  Fire.  After  the  TACAIR  losses,  if  any,  have  been 
entered , the  prog  ram  proceeds  to  checking  the  weapon  system  array  for 
indirect  fire  weapons.  If  none  are  found,  the  program  proceeds  to  a 
subsequent  assessment;  should  either  force  contain  any  indirect  fire 
weapons,  the  indirect  fire  combat  assessment  routine  is  entered.  A 
sample  run  of  this  routine  is  given  in  figure  B»6.  As  with  all  combat 
assessments,  the  first  input  determines  whether  or  not  the  type  of  combat 
being  considered  is  to  be  processed.  In  the  example  of  figure  B»6,  the 
indirect  fire  assessments  are  to  be  processed  and  the  program  proceeds 
to  request  inputs  needed  to  calculate  losses.  Again,  all  possible  inputs 
have  been  illustrated  in  this  example  although  some  might  not  be  asked 
for  at  times.  For  example,  if  the  response  to  "ENTER  # MINUTES  OF  PREP 
FIRE  (0-60)"  is  "0"  (aero),  the  next  entry  specifying  minutes  of  counterprep 
fire,  would  not  be  asked.  Also,  the  question  -HILL  ATTmCKER  DISMOUNT 
irfANTRY  DURING  THIS  Cl?"  is  omitted  whenever  it  is  specified  in  the  rate 
of  advance  routine  that  the  attacker's  infantry  fbrces  are  not  mounted 
(see  figure  B-4).  Finally,  the  entry  of  the  nunber  of  CL6P  missions  to 
fire,  requested  Just  after  the  display  of  fREP/C-PREP  ASSESSMENTS",  is 
only  required  when  the  Blue  weapon  svstem  array  contains  the  appi'opriate 
indirect  fire  weapons.  There  are  only  two  indirect  fire  weapons  cap^Ie 
of  firing  CLGP  missions;  in  this  example,  one  of  these  systems  was  included 


in  the  Blue  force  array.  If  both  were  in  the  weapon  array,  two 
separate  Inputs  would  have  been  required.  After  all  the  different  type 
assessments  have  been  displayed,  the  user  must  Indicate  whether  the 
losses,  as  displayed,  should  be  subtracted  from  the  force.  This  option, 
which  is  presented  at  the  end  of  each  assessment  routine,  allows  the 
user  to  dUregard  a “bad"  run  (e.g.,  an  incorrect  Input  may  have  been 
entered),  and  the  routine  can  then  be  processed  again  at  a later  time. 

c.  Mines.  Following  the  indirect  fire  assessment,  the  program 
checks  whether  mines  are  employed  in  the  Cl  being  gamed  as  specified  in 
rate  of  advance  (see  figure  B-4).  If  so,  the  minefield  assessment 
routine  is  entered  for  processing.  A sample  run  of  this  routine  is 

?iven  in  figure  B-7.  Inputs  for  both  a conventional  and  a FASCAM  mine- 
ield  assessment  are  demonstrated.  For  the* conventional  case,  the 
example  specifies  that  the  Blue  force  does  have  the  capability  to  employ 
mechanical  mine  planters.  If  mechanical  planters  are  not  used,  the 
entries  for  the  number  of  platoons  and  for  the  number  of  hours  are  not 
made.  In  their  place,  three  different  inputs  are  required  for  the 
following:  1)  -ENTER  NUMBER  OF  MEN  USED  TO  EMPUCE  MINES  (MAX-1000)", 

2)  "ENTER  HOURS  AVAILABLE  FOR  EMPLACEMENT  OF  MINES  (MAX-300)",  and  3) 
"SELECT  MINEFIELD  DENSITY".  For  minefield  density,  a selection  is  made 
from  five  different  specified  values,  which  range  from  ,0013  to  .0200 
fflines/sq  meter.  For  the  FASCAM  assessment,  the  input  requirements  are 
always  as  shown  in  the  sample  run  regardless  of  the  type  delivery 
specified.  The  method  of  delivery  entered  for  FASCAM  causes  the  program 
to  access  the  correct  data  (e.g.,  casualty  rates)  in  making  the  loss 
calculations.  It  should  be  noted  that  only  the  defending  force  can 
emplace  minefields.  In  this  example,  the  Blue  force  has  been  designated 
as  the  defender  In  rate  of  advance  (see  figure  6-4);  therefore,  the 
attacker  losses  displayed  in  figure  8-7  are  to  the  Red  force.  Another 
point  to  emphasize  is  that  the  minefield  routine  is  not  exited  until  a 
-0-  (zero)  Is  entered  for  "SELECT  TYPE  OF  MINE  EMPLOYMENT". 

d,  Amor/Antiarmor.  Following  the  minefield  assessment,  if  either 
force  cofilaThi" links  T armor ) or  antitank  weapon  systems,  the  armor/ anti- 
artnor  assessment  routine  is  entered.  As  shown  In  figure  B-8,  this  routine 
requires  minimal  Inputs  from  the  user.  The  primary  requirement  is  to 
enter  a range  index  between  attacker  and  defender.  Multiple  assessments 
can  be  made  by  entering  another  non-aero  range  index  each  time  the  program 
returns  to  that  input  point;  assessments  are  not  stopped  until  a *0"  Is 
entered  for  the  range  index.  The  '"T"‘  input  In  figure  B-8  shows  that 
one  of  six  different  specified  range  bands  can  be  entered  for  the  range 
index  (excluding  zero).  The  maximum  range  between  attacker  and  defender 
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(3,000  meters)  corresponds  to  the  greatest  distance  at  which  the  opposing 
forces  would  engage  in  direct  fire  combat  under  ideal  conditions  of 
visibility.  The  visibility  level  for  the  combat  assessments  Is  specified 
by  the  user  In  the  rate  of  advance  and  has  been  set  to  100  percent  for 
this  sample  run  (see  figure  B-4).  Under  less  than  ideal  visibility 
conditions,  the  maximum  rat^e  for  armor/anti  armor  engagement  is  decreased. 
For  instance,  when  the  visibility  factor  is  set  to  8$  percent,  the 
largest  range  index  that  can  be  entered  here  is  a “5''  (1.e.»  maximum 
range  of  2,500  meters).  Under  the  poorest  visibility  conditions  allowed 
(30  percent),  a “1“  is  the  only  non-zero  input  accepted. 

e.  Infantry.  When  the  armpr/ant i armor  assessments  are  finished,  the 
program  proceed  to  the  infantry  combat  routine.  Infantry  assessments 
can  be  processed  only  if  both  forces  contain  infantry  personnel  in  the 
weapon  system  array;  otherwise,  it  is  bypassed.  The  sample  run  of  tnis 
routine  is  given  in  figure  6-9.  The  input  requirements  are  straight- 
forward; the  oaly  variation  in  the  user  responses  shown  occurs  wh,  ambush 
tactics  are  not  employed,  in  which  case  the  question  •'IS  BLUE  AMBUSHINS 
RED"  is  omitted.  There  is  no  multiple  assessrient  cap?‘'tlity  for  infantry 
combat.  The  inputs  set  the  necessary  parameters  for  the  entire  infantry 
battle  being  gamed,  the  losses  are  calculated  and  displayed,  and  the 
routine  is  ended. 

f.  Attack  Helicopter/ Air  Defense,  The  last  type  of  combat  to  ae 
addressed  for  assissmenli  Ys  altabV  Kelicopter/air  defense.  This  routine 
is  entered  following  completion  of  the  infantry  combat  processing  if 
either  force  contains  attack  helicopters.  The  sawple  run  in  figure  8-10 
demonstrates  the  input  requirements  for  completing  the  helicopter  and 
air  defense  assessments.  In  th»  example,  the  Red  force,  as  indicated, 
contains  no  attack  helicopters;  if  it  does,  the  user  is  first  given  an 
opp*'rtunity  to  game  Blue  ADA  and  Red  A/C.  However*  the  same  Inputs*  from 
set  ’ng  the  AO  weapon  control  factor  to  specifying  whether  another  cell 
of  A/C  is  to  be  flown,  are  required  in  both  cases.  AM  possible  us;r 
responses  are  demonstrated  in  figure  8-16.  It  should  be  noted  that  two 
different  cells  of  Slue  helicopters  are  flown;  the  second  cell  flown 
illustrates  the  capability  of  the  user  to  abort  a helicopter  mission 
before  its  completion  if  losses  incurred  exceed  30  percent.  In  the  case 
presented  here,  that  mission  was  continued  fcr  one  additional  popup* 
then  aborted.  In  the  first  mission  flown,  the  mission  is  messed  to  its 
normal  completion  since  losses  to  the  helicopter  cell  resaain  below  30 
percent,  the  cycle  of  defining  and  assessing  helicopter  cells  can  be 
continued  until  all  sorties  have  been  depleted  or  all  the  beUcopters 
killed.  The  user  determines  when  the  assessments  for  each  he  Vi  cep ter/ 
air  defense  C(^ination  are  terminated.  Upon  coa^Ielion  of  this  routine, 
the  program  returns  to  ll>e  OECISlOh  POINT. 
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Figure  8-5.  Saiaple  run  of  TACAIR  losses. 
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Figure  B-6.  Sample  run  of  indirect  fire  assessments 
(continued  next  page). 


B-17 


.1 

f 

I 


4^RD-vC-PREP  fiSSESSMENTS 

LOCSES  TO  BLUE 
111  R I.Ubf  CREO  LOST 


I 


r 


‘.C‘ 

.lb 

3i 

4S 


l>.  X 

i • '4  *H  I.  c’ 

.0  1.0 

. J . 6 

.E  . 4 

.9  0.3 


f 

t 

i. 

I 


BUJE  LOS-aCS 
[ iEH  # LOST 


TO  RED 
CREW  La5T 


n: 

( ; 

iJO 


. b 
.4 


[ 

I 

T 

X 

X 

I 

I 

I 

f 

I 

T 

1 

I 

i 


ill- 


iNS  TO  FIRE  iMRX=19)  - lO 


Figure  B-6.  Sample  run  of  indirect  fire  assessments 
(continued) . 
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Sample  run  of  Indirect  fire  assessments 
(continued) . 
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-6.  Sample  run  of  indirect  fire  assessments. 
(Concluded) . 
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Figure  B-7.  Sample  run  of  minefield  assessments  (continued  next  page). 
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Figure  B-7.  Sample  run  of  minefield  assessments  (concluded). 


B-22 


BG  ‘i'OU  NISH  TO  WlOCfZSS  ttRMOR-RHTIFiRMOR  V .iif  l ! 1 

HRf  IOR.--RHTI ARMOR  R6SESSMEHTS 

IS  THIS  INITIAL  COMIWT  FOR  THIS  SECTOR?  v 

ENTER  RANGE  INDEX  BETWEEN  ATTACKER  £ DEFENDER  "t 

IF  RANGE  IS  BETWEEN: 

3000  & £501  ENTER  6 
£500  & £001  ENTER  5 
£000  K 1501  ENTER  4 
1500  & 1001  ENTER  3 
1000  & 501  ENTER  £ 

500  & 0 ENTER  1 

»s*T0  STCf  Wis**  ENTER  0 

'■.t  TER  RANGE  INDEX  BETWEEN  ATTACKER  & DEFENDER  4 


BLUE  LOSSES  TO  THIS  POINT 
ITEM  # LOST 
£ 10.£ 

3 .£ 


II 

IS 

U.C 

£5 


•S 

.0 


RED  LOSSES  TO  THIS  POINT 
ITEM  # LC6T 
£ 3.1 

\r  £.1 

£1  .5 

£5  . i 


£0 


.1 


Ft  ITER  RANGE  INDEX  BETtCEN  AHArKFR  ^ iFFFtM'FC'  • • 


Figure  B-8.  Sample  run  of  armor/anti armor  assessmeats. 
(Continued  next  page.) 
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Figure  B-8.  S»nile  run  of  .nnor/entlemor  Bseisments  (concluded) 
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Figure  6*9.  $M|)1e  run  of  Infantry  assessnenta 
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Ficure  B-10.  Sample  run  of  attack  hel1copter/air  defense 
assessments.  (Continued  next  page.) 
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Figure  8-10.  Sai^ple  run  of  tUtck  h«11copter/t1r  defenst  messnents 
(continued). 
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Figure  B-10.  Sample  run  of  attack  helicopter/air  defense  assessments 
(continued) . 
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(concluded). 
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B-7,  LOSS  APPORTIONflENT  AND  BATTLE  STATISTICS.  After  all  the  combat 
has  been  assessed  in  the  Jiffy  Game,  the  losses  that  resulted  must  be 
apportioned  into  the  units  that  were  loaded  into  sector  “T'  and  critical 
incident  “TESTl*’.  The  user  accomplishes  the  loss  apportionment  through 
DECISION  POINT  4.  Figure  B-11  contains  the  sample  run  of  the  loss 
apportionment.  The  user  is  asked  to  indicate  the  level  of  combat 
intensity  in  which  each  unit  loaded  Into  sector  1 has  been  engaged. 

As  shown  In  the  sample  run,  there  are  six  combat  intensity  levels 
(0-5),  After  the  combat  intensity  level  entry  for  R7-6A,  two  appor- 
tionment messages  are  displayed,  which  indicate, that  there  is  an 
Insufficient  number  of  Blue  type  1 weapons  and  Red  type  11  weapons  to 
be  properly  apportioned.  The  apportionment  of  these  types  of  weapons 
must  be  ignored.  This  situation  occurs  generally  to  small  arms  and  other 
dismounted  infantry  systems.  The  assessment  of  these  weapons  is  based 
on  infantry  casualties  and  not  the  number  of  weapons  actually  engaged 
in  combat.  At  this  point,  each  unit  is  subjected  to  the  loss  apportion- 
ment algorithm,  and  its  resulting  unit  effectiveness  is  displayed  as 
shown  in  figure  8-11,  At  the  same  time  a more  comprehensive  output  of 
each  unit,  the  number  and  type  of  weapons  it  lost,  and  the  number  and 
type  of  weapons  remaining  in  the  unit  is  written  on  the  STATS  file, 
a detailed  file  of  the  combat  statistics.  This  portion  of  the  STATS 
file  is  known  as  the  UNIT  STATUS  (see  appendix  C).  After  the  losses 
have  been  apportioned  to  all  unUs  gamed,  the  user  has  the  capability 
to  display  any  unit  and  the  weapons  that  remain  in  it.  After  the  loss 
apportionment  is  completed,  the  user  should  always  exercise  DECISION 
POINT  5,  which  outputs  to  the  STATS  file  the  remainder  of  the  battle 
statistics  as  discussed  in  appendix  C. 
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Figure  8-11.  Sanple  run  of  loss  apportionment. 
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B-8.  TERMINATION.  The  Jiffy  Game  is  ended  through  DECISION  POINT  9. 
Figure  B-12  is  an  example  of  typical  termination  procedures.  In  this 
case,  the  weapon  system  arrays  remaining  in  both  forces  are  first 
displayed  through  the  entry  of  DECISION  POINT  6,  then  DECISION  POINT  9 
is  entered.  At  this  time,  the  user  is  given  a chance  to  update  the 
HISTORYFILE.  The  user  is  asked  if  all  sectors  have  been  gamed.  A 
negative  response  ends  the  program  immediately.  However,  an  affirmative 
reply  first  outputs  the  cumulative  battle  statistics  (see  appendix  C)  to 
the  STATS  file,  then  asks  the  user  if  the  FORCEFILE  should  be  added  to 
the  HISTORYFILE.  Once  again,  an  “N"  (no)  immediately  ends  the  program, 
and  a "Y"  (yes)  copies  the  entire  FORCEFILE  to  the  HISTORYFILE.  It 
should  be  noted  that  all  units  on  the  FORCEFILE,  whether  loaded  into  a 
sector  in  the  critical  incident  being  added  or  not  (in  this  instance 
TESTl),  are  added  to  the  HISTORYFILE.  If  a unit  on  the  FORCEFILE  has 
not  been  loaded  into  a sector  of  TESTl,  it  is  automatically  loaded  into 
sector  0 of  TESTl  before  it  is  added  to  the  HISTORYFILE.  After  the 
program  is  ended,  the  STATS  file  should  be  batched  to  a high-speed  line 
printer.  Note  that  after  the  termination  of  the  run  the  message  "FILE 
QUOTA  EXCEEDED"  is  displayed.  This  is  due  to  a local  maximum  file 
limit  in  existence  on  the  Fort  Leavenworth  computer.  It  merely  means 
that  more  than  20  files  are  attached  to  the  terminal. 
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Figure  B-12,  Termination  of  the  sample  run. 
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APPENDIX  C 


OUTPUT  FROM  JIFFY  GAME  SAMPLE  RUN 


C-1.  PURPOSE  AND  SCOPE.  This  appendix  provides  an  example  and 
discussion  of  the  hard  copy  results  obtained  following  a complete 
run  of  the  Jiffy  Game. 

C-2.  GENERAL.  During  execution  of  some  portions  of  the  Jiffy  Game, 
the  program  creates  a file  containing  detailed  results  of  the  combat 
being  gamed.  This  information  is  not  displayed  on  the  console  screen 
by  the  program  but  is  stored  in  the  local  file  area  of  the  terminal 
and  can  be  printed  out  on  a high  speed  printer  after  the  program  is 
exited.  For  each  sector  of  combat  assessed,  two  major  types  of  infor- 
mation are  made  available  to  the  user  by  this  process.  One  is  a unit 
status  file  of  the  forces  in  the  sector,  and  the  other  is  a series  of 
tables  giving  detailed  combat  loss  data  resulting  from  the  assessments. 
Also,  at  the  end  of  a critical  incident,  another  series  of  tables  giving 
cumulative  loss  statistics  for  all  sectors  in  the  Cl  is  created.  The 
name  of  the  local  file  containing  these  data  is  STATS.  This  file 
should  be  either  printed  out  or  saved  as  a permanent  file  imnediately 
after  the  Jiffy  Game  program  is  ended.  This  information,  if  lost,  can 
only  be  recreated  by  rerunning  an  entire  sector  of  combat. 

C-3.  UNIT  STATUS.  The  input  of  a "4«  at  the  DECISION  POINT  in  the  Jiffy 
Game  initiates  the  apportioning  of  combat  assessment  losses  to  the 
individual  units  that  were  loaded  into  a sector  as  demonstrated  in 
figure  B-11.  As  this  approtionment  is  being  made,  the  program  writes 
the  current  status  of  each  unit  and  each  parent  unit  to  the  STATS  file. 
Figure  C-1  is  an  example  of  this  output  for  those  units  loaded  into  the 
sector  played  in  the  Jiffy  Game  sample  run  of  appendix  B. 

C-4.  SECTOR  LOSS  STATISTICS.  The  execution  of  a "5"  at  the  DECISION' 
POINT  creates  an  output  of  tabulated  combat  loss  statistics,  which  is 
written  onto  the  STATS  file.  A copy  of  the  information  printed  out  at 
the  conclusion  of  the  sample  run  documented  in  appendix  B is  given  in 
figure  C-2.  The  content  and  format  of  these  tables  have  been  developed 
to  provide  meaningful  data  for  analysis  of  the  battle  being  gamed.  With 
the  exception  of  the  ammunition  expenditure  table,  all  the  statistics 
in  this  output  are  derived  directly  from  the  loss  array  created  during  the 
combat  assessment  routines  of  the  Jiffy  Game. 

C-5.  Cl  LOSS  STATISTICS.  When  a "9«  is  entered  for  DECISION  POINT  in  the 
Jiffy  Game,  the  question  "HAS  THE  LAST  SECTOR  BEEN  GAMED  FOR  Cl  (name)?" 
is  asked.  If  a "Y"  is  entered  at  this  point,  the  program  writes  to  the 


STATS  file  the  combat  loss  statistics  cumulated  over  all  sectors  for 
that  Cl.  Figure  C-3  provides  an  example  of  this  output  for  the  Cl 
called  TESTl  that  was  gamed  in  the  Jiffy  Game  sample  run  for  appendix 
B.  Note  that  the  format  and  content  of  the  tables  are  identical  to 
those  for  the  sector  loss  statistics  in  figure  C-2.  In  fact,  since 
only  one  sector  was  played  in  the  sample  run  for  Cl  TESTl,  even  the 
numbers  contained  in  the  figures  C-2  and  C-3  are  the  same. 
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Figure  C-1.  Unit  status  file  (concluded). 


Figure  C-2.  Battle  statistics  (continued  next  page). 


Figure  C-2.  Battle  statistics  (continued). 


Figure  C-2.  Battle  statistics  (continued). 
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Ffgyre  C-2,  Battle  statistics  (continued). 
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Fifi^e  C-2,  Battle  statistics  (continued). 


Figure  C-2,  Battle  statistics  (ojntinued). 


Figure  C-2.  Battle  statistics  (continued). 


Figure  C-2.  Battle  statistics  (continued). 


Figure  C-2.  Battle  statistics  (continued). 


Figure  C-2.  Battle  statistics  (continued). 


Figure  C-2,  Battle  statistics  (continued). 


?Si 

•i 
X M 
MK  I 
»-  I 

U « . 

> Ul  I 

» D J 

« .J 

w m 

j 


O O B 


BOO 

» • • 

BOB 


BOB 


«4  • »o  o cr 


.#  B O K ^ ti 

B *4 


BOO 


o o e o o e 

• •«•#• 

o o o o o o 


B B O B B O O 


O O B B O 


O O O O O 


BOO 


C*  O B 


B o o e o 


o w u 


BOO 


BOO 


BUBO 

• « • * 

O «9  B e 


«4  rvj  N 


C-17 


Figure  C-2,  Battle  statistics  (continued). 


Figure  C-2.  Battle  statistics  (continued). 
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Figure  C-2.  Battle  statistics  (concluded). 


Figure  C-3.  Cumulative  battle  statistics  (continued  next  page). 


Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C-3.  Cumulative  battle  statistics  (continued). 
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Figure  C>3.  Cumulative  battle  statistics  (concluded). 
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APPENDIX  D 


RUN  MODIFICATIONS  FOR  BATCH  PROCESSING 


D-1.  PURPOSE  AND  SCOPE.  This  appendix  addresses  the  requirements  for 
processing  the  Oiffy  Game  programs  in  a batch  operating  mode.  Necessary 
program  modifications  and  procedures  for  completing  a batch  run  are 
described. 

D-2.  GENERAL.  Designed  to  be  an  interactive  computer  model,  the  Jiffy 
Game  and  all  its  associated  programs  require  many  Inputs  during 
execution.  Ideally,  Inputs  are  entered  by  the  user  from  a remote 
Interactive  terminal  as  the  program  Is  being  run.  However,  there  are 
several  calssifled  data  arrays,  stored  In  the  computer  external  to  any 
of  the  coded  programs,  which  must  be  accessed;  and  security  restrictions 
prevent  access  of  this  data  from  most  of  the  remote  terminals  currently 
available  to  Jiffy  Game  users.  To  overcome  this  problem,  a capability 
has  been  developed  for  processing  the  Jiffy  Game  In  a batch  operating 
mode  without  entirely  sacrificing  the  Interaction  between  the  user  and 
the  game.  The  processes  involved  are  diagrammed  in  figure  D-l,  The 
force  file  building  process  Is  Impacted  only  minimally  v^en  the 
classified  data  are  not  accessible. 

0-3,  DATA  REQUIREMENTS.  It  Is  only  the  requirement  to  access  a 
classified  data  file  that  prevents  Interactive  processing  of  the  Jiffy 
Game  programs  on  a nonsecure  teirmlnal.  None  of  the  coded  programs 
contain  classified  infonnatlon,  nor  do  they  create  any  classified  files 
or  output.  Since  It  Is  the  numbers  In  the  data  arrays  that  are  classified. 
It  has  been  possible  to  create  an  ‘'unclassified**  data  file;  that  Is,  a 
file  containing  meaningless  data  values  but  paralleling  the  real  data 
file  In  every  other  respect.  The  CACOA  Jiffy  War  Game  Technical  Manual 
documents  both  sets  of  data.  With  this  unclassified  file  (UNOATA),  the 
entire  Jiffy  Game  can  be  processed  Interactively  from  any  remote 
terminal.  Obviously,  the  results  obtained  by  doing  so  are  meaningless, 
but  this  capability  plays  c ' ey  role  in  creating  a batch  run. 

0-4.  FORCE  FILE  CREATION.  The  force  file  building  procedure  discussed 
In  appendix  A requires  processing  of  four  programs.  Of  these,  only  one, 
the  FORCE  program,  requires  access  to  the  classified  data  file  (CLOATA). 

The  SRCFILE  the  UNITFILE,  and  the  PARENTFILE  all  can  be  constructed 
interactively  from  any  remote  terminal.  The  FORCEFILE  can  also  be  built, 
using  the  unclassified  data  file,  at  a nonsecure  terminal.  Even  when  the 
FORCEFILE  is  developed  with  unclassified  data,  the  unit  records  created 


are  essetv.ially  correct;  the  only  consequence  of  doing  so  is  that  the 
unit,  c'ffc  iveness  values  conputed  for  a unit  must  be  reset  with 
classifie.!  dalc».  A se.par.ate  program,  called  RESET,  is  used  to  make 
this  oi.e-.ii.’ie  correciion  during  the  batch  processing  as  described 
below. 

D-5.  ANSWER  EILE.  As  indicated  in  figure  D-i,  it  is  necessary  to 
create  a 'ile  contain i.ig  the  "ansv/ers"  or  inputs,  required  during 
execution  of  Liie  Jiffy  Game  progra'ii.  Tins  ANSWER  file  is  created  by 
running  the  Jiffy  Game  interactively  from  a remote  terminal  and  inputing 
a "1"  when  asked  to  "ST'ECIFY  PURPOSE  OF  THIS  RUN".  This  causes  the 
program  to  write  each  response,  as  it  is  entered  at  the  terminal,  onto 
a local  file  called  ANSWER.  During  this  type  of  run,  the  user  makes _ 
essentially  the  same  inputs  demonstrated  by  the  sample  run  in  appendix 
B.  Some  differences  may  occur  in  the  combat  assessment  routines 
(paragrapli  B-6).  Since  most  of  the  classified  data  are  used  in  the 
combat  as;;essnient  calculations,  the  losses  computed  during  an  unclassified 
run  ('..e.,  using  the  unclassified  data  file)  have  no  meaning.  Therefore, 
the  displays  of  rate  of  advance  statistics  and  combat  losses  shown  in 
figures  B 4 through  B-10  are  suppressed  during  an  ANSWER  file  creation 
run.  Also,  any  inputs  based  on  losses  previously  calculated  either  are 
not  made  or  are  automatically  adjusted  during  the  batch. run,  An  example 
of  an  input  that  cannot  be  made  during  batch  processing  is  found  in  the 
attack  helicopter/air  defense  routine  (see  figure  B-loj.  Here,  the 
sortie  abort  input  is  made  only  when  lielicopter  losses  reach  a certain 
level.  Since  the  helicoptei  losses  during  the  unclassified  interactive 
run  differ  from  tlinse  during  the  classified  batch  run,  aborting  a 
helicopter  mission  is  automatically  done  by  the  program  in  all  cases 
when  losses  exceed  30  percent.  While  some  inputs  affected  by  calculations 
made  In  the  progi'am  cannot  be  deleted  (e.g.,  the  number  of  A/C  entered 
Into  an  attack  helicopter  cell  as  in  figure  B-10.  or  specifying  the 
number  of  CLGP  missions  to  five  as  in  figure  B-6),  provisions  have  been 
made  in  the  program  to  adjust  tl>om  automatically,  if  necessary,  during 
a batch  run.  After  the  program  has  been  ended,  the  ANSWER  file  that  is 
created  in  the  local  file  area  must  be  catalogued  into  a permanent  file. 

D-6,  BATi.i'l  RUN.  Tlie  actual  batdi  run  of  the  Jiffy  Game  requires  punching 
a job  deck  and  delivering  it  to  tiie  rn".|.t-al  computer  s i le  for  processing, 

A sample  i.ard  deef.  showing  the  rominands  necessary  to  complete  the  run  is 
given  in  ■'Mgure  D- J.  Note  that  the  commands  used  in  tliis  job  deck  are 
basically  tlie  same  as  those  used  to  initiate  an  Interactive  run  in  the 
RUNJIFFY  'Call"  rUc'  (Figure  A-l).  Here,  however,  the  ANSWER  file 
created  by  tl\e  user  must  be  attached,  and  the  command  "JIFFY,  ANSWER"  not 
only  executes  tlie  pi  ugram  but  also  directs  it  to  road  the  inputs  from  the 
ANSWER  file,  Tlio  output  from  this  job  includes  everything  •found  1n  the 
sample  runs  and  onti.nil'.  of  appendixes  B and  C, 
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1 . Job  card . . . 

2.  Task  card... 

3.  ATTACH,  TAPE55,  (force  file)... 

4.  AHACH,  CLDATA,  (classified  data  file)... 

*5.  ATTACH,  RESET,  (source  o)de  file)... 

*6.  FTN.  I=RESET,  L=0. 

*7.  L60. 

8 . ATTACH , TAPES , ( history  file)... 

9.  AHACH,  TAPE9,  (SRC  file)... 

10.  ATTACH,  ANSWEH.(answer  file)... 

11.  AHACH,  JIFFY,  (Jiffy  Game  binary  file)... 

12.  JIFFY,  ANSWER. 

13.  REWIND,  STATS. 

14.  COPY,  STATS,  OUTPUT. 

15.  End  of  file  card 

♦Required  only  If  the  Force  File  has  not  been  reset  or  Initially 
built  with  classified  data. 


Figure  D-2.  Sample  batch  run  Job  deck. 
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